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Preface 



This report provides a detailed documentation on the application of static pro- 
gram analysis to the key establishment protocols of the ZigBee wireless sensor 
network standard. The approach presented in this report is within the scope of 
the SENSORIA (Software Engineering for Service- Oriented Overlay Comput- 
ers) project, and will form a preliminary version of one of the chapters in my 
PhD dissertation. The discovered flaw and the proposed secure protocols were 
recently published in a conference paper (see references [T7]) and also accepted 
for journal publication. 
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Analyzing the Protocols 



Computer networks or simply networks are the main means of information shar- 
ing and communication in today's IT infrastructure. Certain protocols are ex- 
ecuted to facilitate communication in networks. However, such networks are 
mostly insecure and the communication needs to be protected against attackers 
that may influence network traffic and and communication parties that might 
be either dishonest or compromised by attackers. 

Cryptographic security protocols form an essential ingredient of network com- 
munications by ensuring secure communication over insecure networks. These 
protocols use cryptographic primitives to support certain security properties, 
but ensuring this properties requires a lot more effort. Despite the relatively 
small size of the security protocols it is very hard to design them correctly, and 
their analysis is very complicated. One of the most well-known examples is the 
Needham-Schroeder protocol [I], that was proven secure by using BAN logic 
pi. Seventeen years later G. Lowe [3J 0], found a flaw by using an automatic 
tool FDR. The flaw was not detected in the original proof because of different 
assumptions on the intruder model. The fact that this new attack had escaped 
the attention of the experts was an indication of the underestimation of the 
complexity of protocol analysis. This example has shown that protocol analysis 
is critical for assessing the security of such cryptographic protocols. 

In this report, we present our approach for protocol analysis together with a 
real example where we find an important flow in a contemporary wireless sen- 
sor network security protocol. We start by modelling protocols using a specific 
process algebraic formalism called LySa process calculus. We then apply an 
analysis based on a special program analysis technique called control flow anal- 
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ysis. We apply this technique to the ZigBee-2007 End-to-End Application Key 
Establishment Protocol and with the help of the analysis discover an unknown 
flaw. Finally we suggest a fix for the protocol, and verify that the fix works by 
using the same technique. 



1.1 An Overview of the Analysis Method 

Static program analysis, in essence, examines a program statically, before any 
attempt of execution. Although the finite amount of resources may limit the 
information or the answers to important questions, the approximation based 
approach of static program analysis makes it preferable on the area of protocol 
analysis. Instead of facing undecidability problem, this technique sacrifices pre- 
cision and gives approximate answers about a property of a certain program, 
or a piece of code, or a protocol as in our case. However, this loss of precision 
does not mean that we are missing the flaws, it merely means that the analysis 
results may include false positives, such as a bug or a flaw that the program 
does not contain. 

Static program analysis was originally developed for generating codes and opti- 
mising compilers [5J [5]. Nevertheless, the analysis technique have recently been 
directed to the field of security. Encouraging results have been obtained by the 
use of this approach where safe approximations to the set of values or behaviours 
arising during protocol runs can be predicted. 

Control flow analysis of processes formalised in the LySa process calculus suc- 
cessfully computes an over-approximation of the run-time behaviour of a proto- 
col 18] . This method is actually the protocol analysis method that we present 
in this report. The roadmap of the analysis method is given in Fig. 11.11 and we 
will present the steps of this roadmap in the following sections. 



1.2 Modelling in LySa Process Calculus 

The first step in the protocol analysis is to formalise the protocol narration into 
a model that is suitable for the analysis. In our case, we formalize the protocols 
using the LySa process calculus [8]. LySa is based on the 7r-calculus [9] and 
incorporates cryptographic operations using ideas from the Spi-calculus |10j . 
However, LySa has two different properties compared to spi/7r calculus. First, 
LySa has one global ether, instead of channels. The reason for this difference is 



1.2 Modelling in LySa Process Calculus 



3 



1 


Protocol Narration 
I 


1 


Extended Protocol Narration 


1 


I 

1 r- 




LySa Model 1 Attacker Model 
I i 


Static Program Analysis 




Flawed ? | ^ Correct ! 




Figure 1.1: The Roadmap of the Analysis 




Table 1.1: LySa Terms - Symmetric Fragment 




E ::= 




x variable 




n name 




{Ex, . . . , Ek] l E n [dest£] symmetric encryption 



that, in usual networking implementations (e.g. ethernet-based, wireless, etc.), 
anyone can eavesdrop or act as an active attacker which does not correspond 
to the channel-based communication. The second difference is in the pattern 
matching usage in the tests of the expressions associated with input and decryp- 
tion. Although LySa is a very powerful process calculus which also supports 
asymmetric encryption, digital signatures, etc., in order to make it simple we 
only illustrate the symmetric fragment. The symmetric fragment suffices to 
prove our claims in the example that we will present the flaw discovery since 
the protocol is designed for symmetric encryption only. The reader interested 
in further details including the asymmetric fragment may refer to [8]. 

In LySa, we have terms (E) that consist of names (keys, nonces, messages, 
etc.), variables, and the compositions of them using symmetric encryption. The 
syntax of terms is shown in Tabic 11.11 In the case of encryption, the tuples of 
terms E\ , . . . , E^ are encrypted under a term Eq which actually represents an 
encryption key. Note that an assumption of perfect cryptography is adopted, 
which means that decryption with the correct key is the only inverse function 
of encryption. The annotation inside brackets in the end of encryption will be 
explained later in this section. 

The syntax of the processes (P) which is mostly alike to the polyadic Spi- 
calculus [TU] is shown in Table 11.21 At this point, we prefer to skip the syntax 
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Table 1.2: LySa Processes - Symmetric Fragment 



P ::= 




nil 



Pi | P2 



parallel comp. 

replication 

restriction 

output 

input 



IP 

{vn)P 

(E 1 ,...,E k ).P 
(Ei, . . . ,Ej]Xj + i, 



...,x k ).P 



decrypt E as {E\, . . . ,Ef, Xj+i, ■ ■ ■ ,Xk}%\or\gC] inP symm. decryption 



for simple ones in the table, but explain the more interested and complicated 
two: output and input processes. The output process (E\, . . . , E k ).P sends the 
fc-tuplc E±, . . . , Ek to the network and continues as process P. Similarly, the 
input process (Ei, . . . , Ef, Xj+i, . . . , Xk)-P receives a fc-tuple E[, . . . ,E' k and if 
conditions are satisfied, removes the fc-tuple from the network. Here, the input 
operation uses pattern matching which will only succeed if the prefix of the 
input message matches the terms specified before the semi-colon. In a simple 
manner, we can say that for some input E' the input process (E;x).P means 
that if E' can be separated into two parts such that first part pairwise matches 
to the values E, then the remaining part of the input will be bound to the 
variables x. As you can see in Table H21 the number of tuples in E' is k so that 
this is the total number of tuples in E and x. This kind of pattern matching is 
also used in decryption. 

Example l.a The example LySa code below is a new (created - restriction) en- 
cryption key (K) followed by an output which includes three plaintext elements 
(A, B, Ka) and an encrypted element ({K}k a )- 



Example l.b The example LySa code below is an input that binds the last 
two elements of the input to the variables xka and x as long as the first two 
elements are A and B. 



Example l.c The example LySa code below is a decryption that decrypts the 
value bound to variable x using the encryption key bound to variable xka and 
binds the resulting plaintext value to the variable xk ■ Note that this decryption 
always succeeds without any need of pattern matching, as long as the correct key 
exists in the receiver. 



(vK) (A,B,K a ,{K} Ka ) 



(A,B;x KA ,x) 



1.2 Modelling in LySa Process Calculus 
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decrypt x as {; x K } XKA 

In order to describe the message authentication intentions of the protocols, we 
also have annotations for origin and destination. Encryptions can be annotated 
with fixed labels called crypto-points that define their positions in the pro- 
cess, and with assertions that specify the origin and destination of encrypted 
messages. A crypto-point t is an element of some set C and used when encryp- 
tions/decryptions occur. The LySa term for encryption: 

{E u ...,E k y Eo [destC} 

means that the encryption happened at crypto-point I and the assertion [dest 
C] means that corresponding (valid) decryption is to happen at a crypto-point 
that belongs to the set £ such that C C C. Similarly, in the LySa term for 
decryption: 

decrypt E as {E 1: . . .,Ej; x j+1 , . . . ,x k } e Eo [ongC] inP 

[orig C] specifies the crypto-points C C C that E is allowed to have been en- 
crypted. 

Example 2 The example LySa code below is the composition of the three 
separate parts in Example 1, and the necessary annotations in such a way 
that now we have two separate processes running in parallel. 

/*a */ (vK)(A,B,K A ,{K} e A A [dest{l B }}).0 
I 

/*b*/ (A,B;x KA ,x). 

/* c */ decrypt x as {; x K Y X B KA [orig {£ A } ] in .0 

The example we constructed step by step is actually the LySa model of the 
single-message protocol below: 

1. A -> B: KA, {K}^ 

The upper part (line a) of the parallel composition is the code for principal A, 
and the lower part (lines b and c) is for principal B. In this example, annotations 
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Table 1.3: Extended Protocol Narration - Cas e 1 

1. A -y :A, TC, {TC, AppKey, B} KA 

[dest TC] 

1 • ^TC . ^initiator i ^TCi ^message 

[check a; TC =TC] 
1". TC: decrypt x messa g e as 

{•^TC' ^keytypei ^responder} KA 

[orig xa] [check Xy C =TC, x keytype = AppKey] 

2. TC^ :[new LK] 

TC, ^initiator-; 

{^initiator ;AppLK,X reS p 0n der •> 

TRUE,LK} KA 

[dest Xi n itiator\ 
2'. ->-A :yrC) 2M, Vmessage 

[check y T c=TC, y^=A] 
2" . A : decrypt y mesS age as 

{2/A> Ukeytype, 1JB, Vbooh DLk}kA 

[orig TC] [check y' A =A, y keyfype =AppLK] 
[check y B =B, y booi =TRUE] 



state t/iat </ie encryption at crypto-point I a is intended to be decrypted only at 
£b- In a corresponding manner, the decryption at Ib should originate from the 
encryption at I a- 



1.2.1 Specifying Protocols in LySa 



In the beginning, we have a protocol narration like the one in Table 11.71 Then 
we extend the narration to specify the internal actions to be performed in prin- 
cipals when receiving those messages. The reason for this kind of extension or 
conversion is to completely state the actions internal to the principals, which 
are normally left implicit in the narration of security protocols. 

As an example, the extended protocol narration of (due to the lack of space) 
the first two messages of Case 1 is given in Table 11.31 For each message in 
the original protocol narration, we have an output message n and an input 
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message n' in the extended protocol narration. Input message n' presents the 
variable (those written in italics) bindings and necessary checks in the receiver 
side. If a variable is a ciphertcxt and the receiver has the correct encryption 
key, then we have another message (i.e. n") for each of those variables. In 
addition, we explicitly write the internal actions as annotations between square 
brackets, in order to bridge the gap between informal and formal specification 
of the protocol. Note that when analysing protocols we add an extra message 
to the end, where a principal attempts to communicate the other through the 
new shared key, LK. For example, the message 



1. B -> A: {MSG} lk 



does not change the protocol nor bring any (nor bring any additional cost to 
the implementations), it is just a sample message that will be sent using the 
new LK and thus it will ease the validation which is done by checking attackers 
knowledge. 

In the next phase, we convert the extended protocol narration into a LySa 
model. We use the LySa syntax that we explained earlier in this section and 
configure the necessary settings. As an example, a regular LySa model of the 
protocol that we have used to demonstrate extended protocol conversion is given 
in Table 11.41 Further details of specifying protocols in LySa are present in [8] . 



1.3 Static Program Analysis 



Static Analysis is a formal method that enables the security analysis of crypto- 
graphic communication protocols which are modelled as LySa processes. Mes- 
sages communicated on the network are tracked with the possible values of 
the variables in the protocol. Besides, the potential violations of the destina- 
tion/origin annotations are also recorded. The aim of static analysis is to effi- 
ciently compute the safe approximations to the behaviour of the models without 
actually running them. In Fig. |1.2l we can see the approximation approach. In 
general, it is impossible to compute the precise answer so we make a choice 
between over-approximation and under-approximation. Static analysis over- 
approximates the set of possible operations that the LySa process describes. 
The nature of over-approximation may cause the analysis to investigate a trace 
which is impossible at all. However, over-approximation is needed to make a 
safe approximation since under-approximation could miss some traces. 
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Table 1.4: LySa Model - Case 1 





let A L in s.t. [INJ = {1, z, oj- in 




\Vifzx &Ai) (Vjex fttij) 




Hex \ j& xu{0} ! 


1 


(A,, TC^TCAppKey^BjjKA^ataUj dest {tela})). 


2' 


{TC,Ai; m ). 


2" 


dprrvnt n ■■ as (A- ArmT.K R TRUE- tT.K \ „ a 




[d L ? j UNg, ^ LC/O ij f \ 111 






/I" 


decrypt y2 tj as {; xmsg ij } xLKi] [^a4 i j origjfe^^}] in 




hex \iexu{o} ■ 


o) 
o 




O 


decrypt z t j as \Oj , Appni\ , rALiorj, ynJ\ j j j- KB., 




[atfe5 i:( - orig{ic5y }] in 


4 


(i/MSGij) (Bj,Ai, {MSGij} V LK i:j [at destW y }]). 




iexu{o} jexu{o} ! 


1' 


2?y). 


1" 


decrypt ay as {TC , AppKey, Bj; } KAi 




[at icijj orig{aiy }] in 


2 


(v-LITy) (TC^i,^,^^,^-, TRUE, LK 13 } K a z 




[attc2ij dest{o^}])- 


3 


(TC, Bj, {Bj, AppLK, A h FALSE, LK l3 } KB] 




[at tc3ij dest {b3ij}}). 




Figure 1.2: Static Analysis 



1.3 Static Program Analysis 
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1.3.1 Analysis Method 

The static analysis we use in this study is specified as a Flow Logic U] , which 
is based on the control flow analysis and the data flow analysis techniques that 
allow us to make it fully automatic 

Control flow analysis is a program analysis technique that is used to compute 
approximations of the result of a program execution without running the pro- 
gram. Such an analysis helps us in determining the sets of values that may be 
generated by communication using a specific protocol, which is beneficial for 
validating certain security properties. Especially when used in conjunction with 
a model of possible malicious activity (i.e. attacker), the analysis provides a 
safe approximation of all events that may happen. 

Flow Logic is a notational style for specifying analyses across programming 
paradigms, introduced by Nielson, Nielson [12] [13] [14] , and with Hankin [TT] . 
By abstracting from domain specific formalisms and instead using standard 
mathematical notations, the Flow Logic constitutes a meta-language that can 
present an analysis without requiring additional knowledge about particular for- 
malisms. Deriving an analysis estimate from the resulting analysis specification 
is then left as a separate activity, usually involving orthogonal considerations 
and tools. This approach allows the designer to focus on the specification of 
analyses without making compromises dictated by implementation considera- 
tions. Similarly, implementation is simplified and improved, as the implementer 
is always free to choose the best available tool. In the next sections, we will 
present control flow analysis of LySa in the style of flow logic. 

The control flow analysis that we use in protocol analysis is specified using the 
flow logic framework as a predicate 

P,K,1p\= P 

that holds precisely when p, n, and ip form an analysis result that correctly 
describes the behaviour of the process P. 

The main components of the analysis are: 

• The variable environment p, an over-approximation of the potential values 
of each variable that it may be bound to. 

• The network component n, an over-approximation of the set of messages 
that can be communicated over the network. 
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Table 1.5: Analysis for Terms, p \= E:-d 



, . ., •, I n I € $ 

(AName) 



(AVar) 
(AEnc) 



p |= rv.-d 

p \= x:-& 
A?=o/> r= ^ A 



W Q ,V 1 ,...,V k :A? = oVi£0i {Vi,...,VkY Vn [<iestC]e0 
p\={E 1 ,...,E k y En [dest£]:d 

• The error component ip, the set of error messages in the form (£,£'), in- 
dicating that something encrypted at £ was unexpectedly decrypted at 



The analysis is judgments of the form p,K,ip \= P which express that p, re, ip 
compose a valid analysis for the process P. We also need to introduce the 
auxiliary judgment p |= E:-d at this point. This expresses that the set of 
values, is an acceptable estimate of the values that the term E may evaluate in 
p, the abstract environment. 

To keep the analysis component finite, we partition all the names that are 
generated by a LySa process into finitely many equivalence classes. A canonical 
value is a representative for each of these equivalence classes. Names from the 
same equivalence class are assigned a common canonical name and instead of 
the actual names, we use the names of those equivalence classes. For example, 
the canonical representative of a name n is denoted by ["-J ■ Since it allows 
us to analyse an infinite number of principals, canonical value is an important 
analysis element |15) . 

The analysis of terms is listed in Table 11.51 The rule for analysing names 
(AName) states that $ is an acceptable estimate for a name n if the canonical 
representative of n belongs to The rule for analysing variables (AVar) states 
that •& is an acceptable estimate for a variable x if it is a superset of 
The rule for analysing symmetric encryption (AEnc) finds the set $j for each 
term Ei, collects all k-tuples of values (Vo, ■ ■ ■ , V k ) taken from i?o x . . . x d k into 
values of the form {Vi, . . . , V k }y [dest£] and requires that these values belong 
totf. 

The analysis of processes is listed in Table 11.61 The idea of the analysis is very 
similar to the analysis of terms, therefore instead of explaining all the rules we 
explain only one interesting rule. The rule for analysing output (AOut) uses the 
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Table 1.6: Analysis for Processes, (p, k) \= P:tp 



(ANN) (p,K)\=0:1> 

a {p,k)\=p*4 



(APar) 
(ARep) 
(ANew) 



\=P! \P2-4 

(p, k) h ^ 
(p,/t) h 

(p,/c) |= (vri)P:ip 



(AOut) 0, k) (= 

h= (E u ...,E k ).P-4 

A^p \= Eitfi A 
(Aln) (p, K )^P:^ 

Wi,...,V r fc €«:A? =1 V;€tf i => At 7+i y i €p(L^j) A 
(p,/c) \= (E 1 ,...,E J ; x j+1 ,...,x k ).P:ip 

p\=E:tf A 

(ADec) (p, K )^P:^ 

V{y 1 ,...,T4}(, n [dest£] e^:A^ o y, 6^ g- A^Tj g p( [^J ) A 
(p,k) h decrypt g as {E 1 ^ . , x j+1 ,. . . ,x k } e En {or\g£] \nP:ip 



analysis for terms to find the estimate $j for each term Ei and requires that all 
all k-tuples of values (Vi, . . . , V k ) taken from $i x . . . x -d k are in k (i.e. they 
may flow on the network). The rule also requires that the components p,n,tp 
compose a valid analysis for process P. 



Example 3 Static analysis of the LySa model given in Example 2 will lead to 
the following results: 
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{A t B,K A ,{K}% A [deSt£ B ]) G k 
{#}^[dest 4?] epW 

Looking at the results above, it is easy to see that the first line is related to line 
a in Example 2. Likewise, next two lines derived from line b and the last line 
derived from line c in Example 2. Note that, how the analysis works is not the 
subject of this paper. Therefore, see for how Example 2 leads to Example 3. 



1.3.2 Attacker Model 

In practice, network protocols are vulnerable to attacks. Unfortunately it is 
even easier to attack wireless networks since any computer within range that is 
equipped with a wireless client card can pull the signal and access the data. In 
this study, LySa processes are analysed in parallel with the Dolev-Yao attacker 
[16] . The operations that this attacker model can perform are listed below, but 
before this we have to introduce new canonical (see Section 11.3.1(1 names and 
variables for the attacker. All the canonical names of the attacker are mapped 
to n. and all the canonical variables of the attacker are mapped to z % . We also 
have I, which is a crypto-point in the attacker. 

The descriptions of the Dolev-Yao conditions are: 

• The attacker initially has the knowledge of the canonical name n, and 
all free names of the process P but he can improve his knowledge by 
eavesdropping on all messages sent on the network. 

• The attacker can improve his knowledge by decrypting messages with the 
keys he already knows. Unless the intended recipient of the message was 
an attacker, an error (£,£,) should be added to the error component -0 
which means that something encrypted at £ was actually decrypted by the 
attacker at £,. 

• The attacker can construct new encryptions using the keys he already 
knows. If this message is received and decrypted by a principal, then an 
error (£,,£) should be added to the error component ip which means that 
something encrypted at the attacker was decrypted by the attacker by a 
process P at t. 



1.4 Application on ZigBee Wireless Sensor networks 
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• The attacker can send messages on the network using his knowledge and 
thus forge new communications. 

These conditions enable the attacker to establish scenarios including eavesdrop- 
ping, modification, man-in-the-middle and replay attacks. The soundness of the 
Dolev-Yao condition is proved in [8]. 

As shown in Fig. 11.11 the LySa model of a protocol is analysed in parallel with 
the attacker model and processed by the LYSA-tool (see Section 11.4.41) which 
implements the static analysis. The results of the analysis are used to validate 
destination/origin authentication and confidentiality properties of the protocols. 
If no violation is detected, namely the error component ip is empty, then it 
is guaranteed that the protocol satisfies the destination/origin authentication 
properties. Furthermore, the potential values that are learned by the attacker 
help us in validating the confidentiality properties. The details as well as the 
proof of the soundness of the analysis are presented in [7] . 

Example 4 In Example 3, we analysed Example 2 in an attack-free setting. 
Now we add the attacker model and get the following results in addition to the 
results in Example 3. Since the attacker is able to learn everything sent on the 
network we have: 

K A ,{K}^ A [deste B ] €p(z.) 

Therefore, the attacker can decrypt the encrypted part of the message which 
leads to the violation: 

(Ia,1.) eij 

Thus we conclude that the encryption at crypto-point I a which was intended 
to be decrypted at £b can be decrypted by the attacker and hence the example 
protocol is flawed. 

1.4 Application on ZigBee Wireless Sensor net- 
works 

In this section, we present an application of the analysis method that we ex- 
plained up to now [17] . This application has many features that make it in- 
teresting. First of all, it pinpoints an undiscovered and non-trivial flaw in a 
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real cryptographic security protocol. Another key issue is that the protocol is 
being used in one of the latest wireless sensor network standards, ZigBee, that 
is promising and emerging in the sensor networks field. Therefore, the protocol 
includes secure components that are known to be secure when they are indi- 
vidually used and some of them are industry standards such as SKKE that we 
will explain in more details. Still we show that combining proven to be secure 
components is not sufficient for guaranteeing security properties. Last feature 
of this application is that we not only use protocol analysis to discover flaws but 
also to verify our fix proposals. 



1.4.1 ZigBee-2007 End-to-End Application Key Establish- 
ment Protocol 

ZigBee is a fairly new but promising Wireless Personal Area network (WPAN) 
standard for wireless sensor networks that have very low resource requirements. 
In parallel with this, the devices that operate in ZigBee networks have limited 
resources in terms of memory, processor, storage, power, etc. Therefore imple- 
menting the security guarantees is a great challenge and the verification of the 
security properties is of paramount importance. 

We start by presenting the key points that are necessary for a clear under- 
standing of the development, and we omit all the details which are not directly 
relevant to this study. However, a detailed survey on ZigBee security can be 
suggested as [18] and surely the ultimate source is the ZigBee documentation 
[201 EH] [S3] [TS] which is a rather difficult read with hundreds of pages in- 
cluding references to several other standards. 

End-to-End Application Key Establishment is the protocol to be used when es- 
tablishing a Link Key (LK) between two ZigBee devices, which are running in 
High Security Mode (which was called Commercial Mode in the previous stan- 
dard, ZigBee-2006 [H]). We will call the devices as initiator (A) and respondcr 
(B). Note that there is also a Trust Center (TC), which shares a pairwise secret 
key with each principal in the network. TC is actually an application that runs 
on a preferably more powerful ZigBee device referred to as ZigBee Coordinator 
which is unique in the network; whereas the remaining devices might be of type 
ZigBee Router or ZigBee End Device, as shown in Fig. 11.31 For a better under- 
standing we should mention that for two ZigBee devices to establish a secure 
communication, they must share a symmetric key (LK) which they either receive 
from a trusted server (TC) or create mutually using a temporary key received 
from the trusted server. 

The scenarios of End-to-End Application Key Establishment are visualized in 
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Figure 1.3: ZigBee Network Model 




Figure 1.4: ZigBee-2007 End-to-End Application Key Establishment Scenarios 
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Fig. 11.41 The solid lines represent the already secure communication paths, 
labeled by corresponding symmetric encryption keys. The dashed lines represent 
the resulting secure communication paths after a successful protocol run, again 
labeled by corresponding encryption keys. Finally, the dotted lines are the 
messages in the protocol labeled by their sequence numbers and the encryption 
keys they deliver. 



ZigBee-2007 End-to-End Application Key Establishment Protocol has two dif- 
ferent cases according to the configuration of TC, we will call them as Case 1 
and Case 2. In Case 1, TC creates the LK itself and sends it to each principal. 
Therefore, the initiator and the responder have no role in the creation of the LK. 
In Case 2, TC creates a temporary shared key called Master Key (MK) and 
sends it to each principal. Using this MK, A and B initiate a Symmetric-Key 
Key Establishment (SKKE) procedure to establish an LK. This case allows 
principals to create an LK mutually. SKKE is actually a key agreement scheme 
employed in the ZigBee End-to-End Application Key Establishment mechanism, 
and its components are defined in the ANSI X9. 63-2001 standard [25]. At the 
end of (a successful run of) either case, two ZigBee devices will be able to 
establish secure communication using their pairwise encryption key, LK. 



1.4.1.1 Case 1 



In Case 1, the initiator begins the procedure of establishing an LK with the 
responder by sending TC the first message, request key, which includes desti- 
nation address (=TC), requested key type (=Application Key), and partner address 
(=b). Then TC creates an LK for two principals, and sends it to each principal 
in two similar transport key messages. Since TC is configured to send an LK 
directly in this case, the key type value in the last two messages will be Appli- 
cation Link Key (AppLK). The only difference between these two messages is a 
boolean value that indicates the initiator (TRUE: message recipient is the initia- 
tor, FALSE: message recipient is the responder), and also the principal address'. 
All the messages in this case are encrypted with the sender/receiver principal's 
key that is shared with TC (assuming that the security suite is Encryption- 
only). The type of this key can either be Trust Center Link Key (TCLK) or 
Trust Center Master Key (TCMK), as defined in the ZigBee specification [20] . 
but for simplicity we will call it KA for principal A, and KB for principal B. 
The protocol narration of Case 1 is given in Table 11.71 
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Table 1.7: Protocol Narration - Case 1 

1. A^TC: {TC, AppKey, B} KA 

2. TC^A: {A, AppLK, B, TRUE, LK} KA 

3. TC^B: {B, AppLK, A, FALSE, LK} KB 



Table 1.8: Protocol Narration - Case 2 

1. A^TC: {TC, AppKey, B}^ 

2. TC^A: {A, AppMK, B, TRUE, MK}^ 

3. TC^B: {B, AppMK, A, FALSE, MK} KB 

4. A^B: {B, FALSE, Zero, SKKE} MK 

5. B^A: {A, TRUE}a/_r" 

6. A^B: {NA} MK 

7. B^A: {NB} MK 

8. A^B: MAC{3 ) A,B,NA,NB} Jf(M AC{A .B,NA,NB}mk,1) 

9. B^A: MAC{2,B,A,NB,NA} H(MA ciA,B,NA,NB} MK ,i) 

1.4.1.2 Case 2 

In Case 2, the first three messages are almost the same as in Case 1, except in 
this case TC is configured to send MK, and therefore key type is the Application 
Master Key (AppMK). The rest of the messages are between the initiator and 
the responder. In the fourth message, establish key, A sends B his request to 
start SKKE. The values, False and Zero, indicate that there is no parent (router, 
TC, etc.), and no parent address, respectively. The fifth message is the response 
of B to A's SKKE request. Note that these two messages are encrypted by MK, 
which was received in the previous two messages. The remaining four messages 
are actually the SKKE protocol itself. Messages 6 and 7 include the challenges 
(NA, NB) of the principals. Messages 8 and 9 are the complex messages which 
can be computed by both parties to verify each other. A and B create two mes- 
sage authentication codes (MAC) using their knowledge, besides the MAC key 
itself is a hash (H) of another MAC which they produce using the same knowl- 
edge [26]. After the verification, the new LK will be H(MAC{A,B,NA,NB} M K , 
2), which is a minor variation of the MAC key that was used in the last two 
messages. The protocol narration of Case 2 is given in Table [T751 



1.4.2 The Flaw 

In wireless networks, it is easy to intercept, forge and inject messages. Without 
any formal analysis, an experienced eye can see that all the messages in ZigBee- 
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2007 End-to-End Application Key Establishment Protocol can be replayed when 
the same long-term encryption keys (KA, KB) are still being used. The reason 
is the lack of freshness elements like nonces, timestamps, etc. This flaw can lead 
to serious replay attacks, denial of service (DoS) attacks, etc. Even worse, when 
an old session key is compromised, an attacker can decrypt all the messages 
by replaying that old session key. In other words, lack of freshness can cause 
failures in authenticity (in the case that principals accept an old session key 
from a rogue TC) and confidentiality (in the case that principals start using a 
compromised session key). 

As can be seen in the narration of the protocol, no freshness indicator is used 
in the distribution of either LK (in Case 1) or MK (in Case 2, the first three 
messages). Therefore, all the messages can be replayed. Replay of a message 
that includes a key is very critical. An attacker can store a message including 
a key from a previous run of this protocol, and then send the old message to 
make principals communicate using this old key. If the old key is compromised, 
then the attacker will be able to decrypt all the messages between two victim 
principals. 

The significance of the security risk that is caused by this flaw may require more 
explanation. Indeed, the flaw does not disclose any session key but allow reuse of 
a former key. Besides, brute force attacks or other types of known cryptographic 
attacks for obtaining the key do not seem practical for the current specification 
(i.e. the keys are 128-bits). However, disclosure of a key might still be possible 
without dealing with cryptography, and reuse of an old session key can cause 
serious risks. An example scenario is given below: 

Scenario 1 A and B established a link key, and had secure communication 
with the help of that pairwise key. Than B left the network and disclosed the 
key, which might be by means of hardware (e.g. local key extraction from the 
chipset such as connecting a debugger, erasing the chip, then freely reading the 
contents of RAM), or software (e.g. a bug in the implementation that discloses 
the key after the session expires or terminates with the natural assumption that 
a new session key will be used for a future session) defects. If B rejoins the 
network, and run the key establishment protocol with A (no matter which case 
or security level is chosen), the disclosed key may be replayed by the attacker 
who can decrypt all the communication using the disclosed key. 

In the ZigBee Specification, the notion of frame counter is emphasized as the 
freshness protection. This approach is not a strong one for several reasons. First 
of all, a frame counter uses incrementing values rather than random values and 
rejects frames with a smaller counter value. Second, regardless of the length 
(which is 32-bits in ZigBee) it is easy to cause overflow to frame counters. As 
indicated in |27] . if an adversary forges a frame with the maximum value (i.e. 
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Table 1.9: Attack Scenario - Case 1 

1. A^TC: {TC, AppKey, B} KA 

2. TC^A: {A, AppLK, B, TRUE, LK} KA 

3. TC^B: {B, AppLK, A, FALSE, LK} KB 
V. A^TC: {TC, AppKey, B} KA 

2'. M(TC)^A: {A, AppLK, B, TRUE, LK} KA 
3'. M(TC)^B: {B, AppLK, A, FALSE, LK} KB 



OxFFFFFFFF) any further frame will be rejected. In addition, using counters 
is not a novel approach, since in such layered architectures lower layers also used 
similar counters. 



1.4.2.1 Flaw in Case 1 

The attack scenario for Case 1 is given in Table [L~9"l The hrst run (messages 1 
to 3), is an old run which is intercepted by an attacker. Here, it is appropriate 
to mention that LK is used like a session key and KA/KB are used like master 
keys. Therefore, KA and KB are possibly the same in two different runs. The 
second run in the attack scenario (messages V to 3') is initiated regularly, but 
the last two messages are replayed by the attacker using the messages that are 
captured from the old run. Furthermore, the attacker does not necessarily need 
to wait for a message like 1' since he can already replay it, too. 



1.4.2.2 Flaw in Case 2 

The attack for Case 1 is also possible for Case 2, in which MK is sent without 
any freshness indicator. Even though LK is created mutually by the use of 
SKKE in Case 2, a compromised old MK that is replayed to principals before 
SKKE will allow an attacker to create the LK as well. The attack scenario for 
Case 2 is given in Table 11.101 The first run (messages 1 to 9) is the old run and 
it is sufficient for an attacker to capture messages 2 and 3. Then the attacker 
replays these messages in the new run (messages 1' to 9'). Although the nonce's 
used in SKKE (exchanged in messages 6 and 7) are different, as long as MK is 
compromised the attacker can decrypt these messages and learn the nonces as 
well. As a result, the attacker can still compute the new LK which is actually 
H(MAC{A,B,NA',NB'}a/k , 2) (see Section ITXTj) . Therefore, we may conclude 
that the flaw is critical in both cases. 
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Table 1.10: Attack Scenario - Case 2 

1. A^TC: {TC, AppKey, B} KA 

2. TC^A: {A, AppMK, B, TRUE, MK} KA 

3. TC^B: {B, AppMK, A, FALSE, MK} KB 

4. A^B: {B, FALSE, Zero, SKKE} M K 

5. B->A: {A, TRUE} M K 

6. A^B: {NA} MK 

7. B^A: {NB} MK 

8. A^B: MAC{3,A,B,NA,NB} ff( MAC{A,B.ATA,Jvs} M K.i) 

9. B->A: MAC{2,B,A,NB,NA} g(MACf A|B . J v A|JVB>Mir , 1) 
1'. A^TC: {TC, AppKey, B} KA 

2'. M(TC)^A: {A, AppMK, B, TRUE, MK} KA 
3'. M(TC)^B: {B, AppMK, A, FALSE, MK} KB 
4'. A^B: {B, FALSE, Zero, SKKE} M K 
5'. B^A: {A, TRUE} MX 
6'. A^B: {NA'}mk 
V. B^A: {NB'} Mif 

8'.A^B:MAC{3,A,B,NA',NB'} ff(M AC{A,B,iVA',iVB'}„ K ,i) 
9'.B-»A:MAC{2,B,A,NB',NA'} g(MAC |A,B,iVA',JVB'i Mjr ,i) 

I. 4.3 Proposed Fixed Protocols 

We propose fixed protocols that use nonces to ensure freshness of the messages 
and at the same time the keys. We make use of the vital principles defined on 
[2"5] . The narrations of our proposed solution are given in Table 11.111 and Table 

II. 12l for Case 1 and Case 2, respectively. 

In Case 1, we added the nonce of the initiator (NA) to the first two messages. 
This will ensure that when receiving the second message, A will believe that 
she is communicating with the TC who knows her nonce and also her private 
key. Note that message 1 can still be replayed but it will be ignored if A does 
not verify message 2. We inserted two more messages before the last message, 
so that we use nonces of the TC (NTC) and the responder (NB) to avoid 
replay attacks. This will ensure that when receiving the fifth message, B will 
believe that he is communicating with TC who knows his nonce. Also note that 
message 3 can still be replayed but the process will be ignored if B does not 
verify message 5. 

Our solution is also applicable to the leaked MK problem in Case 2. Similar to 
our solution for Case 1, we change the first three messages of Case 2 with five 
messages that are also given in Table n~T2"l Not to confuse with the nonces used 
in SKKE, the nonces we added are called (preNA) and (preNB) in Case 2. 
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Tabic 1.11: Proposed Fix - Case 1 

1. A^TC: {TC, AppKey, B, NA} KA 

2. TC^A: {A, AppLK, B, TRUE, NA, LK} KA 

3. TC^B: {B, A, NTC} K b 

4. B^TC: {TC, A, NTC, NB} KB 

5. TC^B: {B, AppLK, A, FALSE, NB, LK} KB 



Table 1.12: Proposed Fix - Case 2 

1. A^TC: {TC, AppKey, B, preNA}^ 

2. TC^A: {A, AppMK, B, TRUE, preNA, MK} KA 

3. TC^B: {B, A, NTC} KB 

4. B^TC: {TC, A, NTC, preNB} K s 

5. TC^B: {B, AppMK, A, FALSE, prcNB, MK} KB 

6. A^B: {B, FALSE, Zero, SKKE} M *r 

7. B^A: {A, TRUE} M *r 

8. A^B: {NA} MK 

9. B^A: {NB} MK 

10. A^B: MAC{3,A,B,NA,NB} Jf( MAC{A,B,iVA,ivs}„ K ,i) 

11. B^A: MAC{2,B,A,NB,NA} h(MAC {a,b,na,nb} mic ,i) 

The fix that we propose is a mechanism that suffices to fix the flaws in the 
original protocol. There might be other ways to fix, but this is a solution that 
simply works and has proven (by formal verification) to be secure. 

Obviously, the proposed solution would come at a particular cost. Particularly, 
the number of messages in each protocol is increased by two, and the usage of 
nonces are required. Transmission of more messages means more power con- 
sumption, but for security critical applications (e.g. in Smart Energy, Com- 
mercial Building Automation, etc.) this kind of fix which ensures that TC is 
authenticated to both A and B (i.e. the new LK is not replayed) is necessary, 
so the additional messages are inevitable. Besides the original protocol in Case 
2 already has nine messages (whereas the primitive version, Case 1, only has 
three) , which is a proof that in order to have a sound protocol ZigBee may have 
longer protocols for the same purpose. The usage of nonces is not a new cost 
since it is already in SKKE which is employed by Case 2. However, the freshness 
is preserved for only SKKE but not the protocol itself due to the design mistake 
of the wrapping protocol. 

As we mentioned before, the flaw in End-to-End Application Key Establishment 
protocol may be visible to an experienced eye but to claim that a fix is flawless, 
verification using formal methods is crucial. Static analysis with LySa is one of 
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the methods that can be used, which has many advantages such as scalability 
and the guarantee of termination. 



I. 4.4 Formal Verification Details 

Analysing security protocols without any formal verification method is not a 
reliable way to find flaws, nor to guarantee that there are no flaws. To make 
our assertions and arguments sound, we use static analysis to analyse protocols. 
To be finite, this method is computing over-approximations rather than exact 
answers, and therefore may lead to false positives. However, when the analysis 
results tell that the protocol is error-free, then it really is. In other words, no 
simulation or verification is necessary when the protocols successfully passes 
static analysis. 

The base protocols in Section 11-4.11 are modelled using LySa process calculus 
and analysed using the LySA-tooQ- The result supports our claims in Section 

II. 4.21 The base protocols are prone to replay attacks which will cause serious 
problems in the case of a leaking key. 

The proposed protocols in Section 11.4.31 are also modelled analysed in the same 
way with the base protocol. The result is successful, namely the proposed 
protocols do not have any flaws. 

The settings that we use to implement the LySa model and verify in the LySa- 
tool are listed below: 

• we check for the origin and destination addresses in each message (by 
adding them as prefixes such as in IPv4 or IPv6) 

• we have the necessary annotations for the encryptions and decryptions 

• we allow legitimate attackers in addition to the illegitimate attackers (by 
adding appropriate zero indices, namely attacker also shares master key 
with TC) 

• we model three groups of (infinite) principals so that we can model man- 
in-the-middle attacks 

• we add an extra message that is encrypted using the session key (to see 
whether the compromised key can be used) 

1 http: / /www. imm.dtu.dk/English/Rcsearch/Language-Based_Technology/Research/LySa.aspx 
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• we check all the fields in the messages to have proper values (by pattern 
matching), except session keys which are newly created (and bound to 
variables in inputs) 

To distinguish between old rounds and new rounds of the protocol we apply a 
new technique in LySa. We add round indicators to the end of pattern-matched 
fields in messages and match them in a smart way to distinguish old runs. Using 
this technique, we can investigate replay attacks successfully. 



1.5 Conclusion 

Analysing protocols is not a trivial issue, and in this work we presented an 
analysis method with a detailed application on a new and so called advanced 
security protocol that uses secure components. 

In this approach, we have solid benefits in mainly: 

• solutions always exist and are computed in low polynomial time. This is an 
important advantage because approaches based on model checking cannot 
always guarantee termination, and besides prone to state space explosion 
problem. Besides the analysis is correct with respect to formal operational 
semantics, which may be hard to establish in different approaches such as 
the ones based on modal logic of beliefs (BAN) where the completeness 
property does not generally hold. 

However, those benefits come with a particular cost: 

• lack of trace and counter-example. Due to the nature of the analysis, there 
is no trace and no produced counter-example to help flaw discovery. As 
a result of the over-approximation, false positives may occur and manual 
inspection is required to match the reported violations to actual flaws. 

Another thing we have presented was the usage of protocol analysis in suggesting 
a secured version of a flawed protocol. Fixing the flaws and proposing secure 
protocols is another non-trivial job. In this manner, we made use of prudent 
engineering practices of Gordon and Abadi, and benefited fruitful discussions 
with Gavin Lowe. One of the points we emphasized was the importance of 
freshness, and the importance of proper usage of freshness indicators such as 
nonces, challenges, etc. 
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We can recapitulate as encryption is not synonymous with security, and its 
improper use can lead to errors. The proper use should be verified by protocol 
analysis methods that focus on certain security properties. Along the way in this 
study, we discovered and documented general guidelines about how to use static 
analysis for protocol validation. We do believe that such studies are necessary 
in order to standardise protocols that live up to their stated expectations. 
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